'\" te
.\" Copyright 2014 Nexenta Systems, Inc.  All rights reserved.
.\"  Copyright (c) 2008, Sun Microsystems, Inc. All Rights Reserved
.\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License").  You may not use this file except in compliance with the License.
.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.  See the License for the specific language governing permissions and limitations under the License.
.\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE.  If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
.TH KERBEROS 7 "November 22, 2021"
.SH NAME
kerberos \- overview of Solaris Kerberos implementation
.SH DESCRIPTION
The Solaris Kerberos implementation, hereafter sometimes shortened to
"Kerberos," authenticates clients in a network environment, allowing for secure
transactions. (A client may be a user or a network service.) Kerberos validates
the identity of a client and the authenticity of transferred data. Kerberos is
a \fIsingle-sign-on\fR system, meaning that a user needs to provide a password
only at the beginning of a session. The Solaris Kerberos implementation is
based on the Kerberos(TM) system developed at \fBMIT\fR, and is compatible with
Kerberos V5 systems over heterogeneous networks.
.sp
.LP
Kerberos works by granting clients \fItickets\fR, which uniquely identify a
client, and which have a finite lifetime. A client possessing a ticket is
automatically validated for network services for which it is entitled; for
example, a user with a valid Kerberos ticket may rlogin into another machine
running Kerberos without having to identify itself. Because each client has a
unique ticket, its identity is guaranteed.
.sp
.LP
To obtain tickets, a client must first initialize the Kerberos session, either
by using the \fBkinit\fR(1) command or a \fBPAM\fR module. (See
\fBpam_krb5\fR(7)). \fBkinit\fR prompts for a password, and then communicates
with a \fIKey Distribution Center\fR (\fBKDC\fR). The \fBKDC\fR returns a
\fITicket-Granting Ticket\fR (\fBTGT\fR) and prompts for a confirmation
password. If the client confirms the password, it can use the Ticket-Granting
Ticket to obtain tickets for specific network services. Because tickets are
granted transparently, the user need not worry about their management. Current
tickets may be viewed by using the \fBklist\fR(1) command.
.sp
.LP
Tickets are valid according to the system \fIpolicy\fR set up at installation
time. For example, tickets have a default lifetime for which they are valid. A
policy may further dictate that privileged tickets, such as those belonging to
root, have very short lifetimes. Policies may allow some defaults to be
overruled; for example, a client may request a ticket with a lifetime greater
or less than the default.
.sp
.LP
Tickets can be renewed using \fBkinit\fR. Tickets are also \fIforwardable\fR,
allowing you to use a ticket granted on one machine on a different host.
Tickets can be destroyed by using \fBkdestroy\fR(1). It is a good idea to
include a call to \fBkdestroy\fR in your \fB\&.logout\fR file.
.sp
.LP
Under Kerberos, a client is referred to as a \fIprincipal\fR. A principal takes
the following form:
.sp
.in +2
.nf
primary/instance@REALM
.fi
.in -2
.sp

.sp
.ne 2
.na
\fBprimary\fR
.ad
.RS 12n
A user, a host, or a service.
.RE

.sp
.ne 2
.na
\fBinstance\fR
.ad
.RS 12n
A qualification of the primary. If the primary is a host \(em indicated by the
keyword \fBhost\fR\(em then the instance is the fully-qualified domain name of
that host. If the primary is a user or service, then the instance is optional.
Some instances, such as \fBadmin\fR or \fBroot\fR, are privileged.
.RE

.sp
.ne 2
.na
\fBrealm\fR
.ad
.RS 12n
The Kerberos equivalent of a domain; in fact, in most cases the realm is
directly mapped to a \fBDNS\fR domain name. Kerberos realms are given in
upper-case only. For examples of principal names, see the EXAMPLES.
.RE

.sp
.LP
By taking advantage of the General Security Services \fBAPI\fR (\fBGSS-API\fR),
Kerberos offers, besides user authentication, two other types of security
service: \fIintegrity\fR, which authenticates the validity of transmitted data,
and \fIprivacy\fR, which encrypts transmitted data. Developers can take
advantage of the \fBGSS-API\fR through the use of the RPCSEC_GSS \fBAPI\fR
interface (see \fBrpcsec_gss\fR(3NSL)).
.SH EXAMPLES
\fBExample 1 \fRExamples of valid principal names
.sp
.LP
The following are examples of valid principal names:

.sp
.in +2
.nf
	joe
	joe/admin
	joe@ENG.EXAMPLE.COM
	joe/admin@ENG.EXAMPLE.COM
	rlogin/bigmachine.eng.example.com@ENG.EXAMPLE.COM
	host/bigmachine.eng.example.com@ENG.EXAMPLE.COM
.fi
.in -2
.sp

.sp
.LP
The first four cases are \fIuser principals\fR. In the first two cases, it is
assumed that the user \fBjoe\fR is in the same realm as the client, so no realm
is specified. Note that \fBjoe\fR and \fBjoe/admin\fR are different principals,
even if the same user uses them; \fBjoe/admin\fR has different privileges from
\fBjoe\fR. The fifth case is a \fIservice principal\fR, while the final case is
a \fIhost principal\fR. The word \fBhost\fR is required for host principals.
With host principals, the instance is the fully qualified hostname. Note that
the words \fBadmin\fR and \fBhost\fR are reserved keywords.

.SH SEE ALSO
.BR kdestroy (1),
.BR kinit (1),
.BR klist (1),
.BR kpasswd (1),
.BR krb5.conf (5),
.BR krb5envvar (7)
.sp
.LP
\fISystem Administration Guide: Security Services\fR
.SH NOTES
In previous releases of the Solaris operating system, the Solaris Kerberos
implementation was referred to as the "Sun Enterprise Authentication Mechanism"
(SEAM).
.sp
.LP
If you enter your username and \fBkinit\fR responds with this message:
.sp
.in +2
.nf
Principal unknown (kerberos)
.fi
.in -2
.sp

.sp
.LP
you have not been registered as a Kerberos user. See your system administrator
or the \fISystem Administration Guide: Security Services\fR.
